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Abstntf 

MBgfctfstabases make use of Ihice levels of abstraction, namcEy: the data dictionary, the database schema and the 
databtf* eontents. The data dictionaTy describes the structure of the database schema whilst the database schema 
desctto^c structure of the database contents. This approach fits perfectly in situations with large quantities of 
"simplf^^ta and relatively small and stable structures. In this paper, we will focus on "product models'* which 
canntflc modelled easily with these levels of abstraction. We will illustrate the modelling problem with an example 
and pM*B* ft solution using the Leeds Product Data Editor. 



TlR«e of databases is possibly as old as 
writiii^ Both merchants and armies created lists 
of iiiMed data, more than 2000 years ago. 
OnorA^ list (database) structure was defined^ 
datawl'^ ^ added to the list by Slling in the 
neccOT attributes. This centuiy the use of for- 
matiAifata has increased dramatically, espe- 
ciaHy* S^yv^nimental organizations and large 
coufVESw Information about citizens, for exam- 
ple, iMced in tens of databases with hundreds 
of aliates describing specific characteristics of 



the s e citizen s,— Co mpanyHjwn e d databa ses f o r 
customers, suppliers and employees add even 
more attributes to this list. All these databases 
have a relatively stable database schema in that 
the structure of the data that is stored will not 
change considerably over time* This stability is 
accompanied by large quantities of repetitive data, 
often thousands or millions of occurrences of a 
certain structure* Ctomputer-based information 
systems that are built on top of these databases 
are especially good in processing these large 
quantities of data. 

The last decade, however, has shown a consid- 
erable growth of nontraditional applications, like 
personal information management systems, com* 
>aided co-operative work systems and com- 
r-atded engineering systems [1]. Features that 
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Fig. 2. Product family stfuciure. 

Specific (manufacturing) documentation for that 
specification (Fig. 1) [2}, 

In order to enable the generation of a product 
variant description, specifically for a given cus- 
tomer specification, a product family description 
must be available. The creation of such a family 
description is normally the responsibility of mar- 
ket ing> engineering and design. It is an example 
of data where structural data is intertwined with 
repetitive data and shared between different 
users, 

ExanifAe 

Consider, for example, a car family. A car is, 
amongst other things, assembled from a chassis, 
an engine, a gearbox and an interior. The interior 
is assembled from the seats and the dashboard 
(see Fig. 2), The relationships between the differ- 
ent parts of the car are structural data, while the 
parts themselves are repetitive data which may 

_tts<?.lf he structured. . 

Further, a n^imber of views can be determined, 
each having its specific requirements in the orga- 
nization* The design process of such a car in- 
volves two different types of activity and produces 
data on different abstraction levels, namely; 

- "structural data", shared by all cars of that 
family which defines the structure of a car; 

- repetitive data", which details the compo» 
ncnts of a car. 

These different abstraction levels will be eluci- 
dated in the next section. First we will continue 
witti this example. 

Each of the aforementioned sub-assemblies can 
be considered as a product family. The interior, 
for cjcample, is a product family which is assem- 
bled from the scats and the dashboard. AJl prod- 



uct families have a number of variants. The vari- 
ety of the car family originates from the variety of 
its sub-assemblies. In turn, the variety of the 
interior originates from its sub-assemblies, i.e. of 
the seats and the dashboard. 

The data structures behind today's engineering 
databases [3,4] typically necessitate the definition 
of every variant of a product family. This means 
the need for the separate description of possibly 
millions of variants of a car, where each descrip- 
tion has a large commonality with descriptions of 
other variants. This redundancy of data is nor- 
mally not acceptable. 

When variants of a product family are physi- 
cally assembled from component variants, it is 
possible to build the descriptions of the variants. 
The description of a car variant can be built 
from; 

- the descriptions of the chassis, engine, gearbox 
and interior variants; plus 

- the description of the car family (e.g. how do 
the component families fit together). 

For example, the description of an interior 
variant can be built from the descriptions of the 
seat and dashboard variants, plus some informa- 
tion about interiors in general (e.g. how seat and 
dashboard families are normally assembled). Fig. 
3 shows the built descriptions in black and the 
basic descriptions in white. Basic descriptions be- 
long to basic, or so-called primary variants, while 
built descriptions belong to so-called assembly 

variants. 

For the purpose of Ws paper, we will assume 
that all assemblies arc assembled to customer 
order. The generation of product descriptions for 




Fig. 3. Building doctimentaiion of isscmbled variants. 
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Fig. 4. Examples of classification. 



Limitations of conventional database systems 

Redundancy of data is introduced when these 
abstraction levels are unplemented in separate 
three-layer databases: 

The first type of redundancy concerns the dif- 
ferent abstraction levels. It is not possible to 
model four levels of abstraction without repeating 
structural data in one database as repetitive data 
in another database. Conventional relational or 
object-oriented databases have only three levels, 
namely: data dictionary, tables/ classes and tu- 
ples/instances. 

The second type of redundancy concerns re- 
dundancy within a single level. Database tables 
(for example for variants of the engine and the 
gearbox) vvill have a number of similar attributes, 
which are repeated for tables. An example is 
given in Section 4.1. 

The next section describes how today's tech- 
niqties deal with the modelling of abstraction 



i^wti 4. Current practices and Insights 



In this section, we will describe three different 
approaches before we elaborate a fourth ap- 
proach, which is based on the Leeds Product 
Data Editor, in Section 5. Firstly, we will discuss 
an implementation in a relational database. Sec- 
ondly, we will describe the advantages and short- 
comings of object-oriented databases. Finally, we 
will show a fundamentally different approach 
(3D1S) which has been proposed by Afsarmancsh 
and McLeod [1]. 



levels and data redundancy in general. It is shown 
that even modem object-oriented databases are 
not powerful ciiough to model this problem con- 
ceptually right. More advanced, but still aca- 
demic, approaches offer better solutions. 



4d, Relational approach 

Relational databases make a clear distinction 
between data and structure [6]. Normally, there is 
a large volume of data and only a relatively small 
and stable structure. This structure is often called 
the database schema and is used by application 
programmes to work on the data. According to 
our previous figure, we will need a number of 
different, however related databases: 

- "car development" as a project database for 
"specific product families" (see Table 2); 

- several databases for product families, e,g. 

"engine" and ^'gearbox" (see Tables 3 and 4). 

From this example, it can be seen that "en- 
gine" and "gearbox" appear both on the data 
level (Table 2), and on the schema level (Tables 3 
and 4). 

In this way data redunoancy over different 
levels of abstraction is introduced. Further, the 
engine (gearbox) information that is presented in 
Table 2 is valid for all design variants of that 
engine (gearbox) which can be found in Table 3 



Table 2 

Attn buKa and data for ''car devetopmcnt" 

Product family Responsibility Family start 

name <^*te 

St pTBrfiuis 1992.10 

Engine H. Heggc 1993-3 

Gearbox Platier 1993-3 

Interior ^ Slckel 1995-7 

Chassis T Renkema 1992-10 



Family finUh Main product relationships 

date 

1995-2 Engine, Gearbox 

1994-8 Ignition, Gearbox 

1994-6 Interior. Engine 

1994-1 1 Dashboard, Seats 

1993-12 Interior, Suspension 
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Fig. 5, Inheritance of structural infonnation. 



4,3^ 3DIS approach 

Afsannanesh and McLcod [1] propose a 
database where all information including the data, 
the descriptions and classifications of data 
(mela-data), abstractions, operations, and con- 
straints arc treated uniformly as objects. Within 
this framework, 3DIS incorporates several prede- 
fined abstraction primitives, including a general- 
ization hierarchy* 

Objects and mappings are the two basic mod- 
elling constructs in 3DIS. Relationships among 
objects are modelled by **(domain-objcct, map- 
ping-object, range-object)" triples. The structure 
of these triples is very much like the binary rcJa- 
tionships in the binary semantic model tSl- Beiow 
some mappings arc given, which are used for the 
car example in Figs. 6-8: 



Member/ type mappings 

- instantiation: Has-member: type objects 
Katomic/ composite objects) 

- classification: (Is-a-mcmber-oO 
Member-mapping/ type mappings 

- decomposition: Has-mcmbcr-mapping: type 
objects P(mcmber-mappings) 

- aggregation: (Is-a-member-mapping-oO 

( Product. Hai-member-DUfiptQg, { 

Htt-product-famUy-Qsnie* 

Has*rcspocisib'iluy, 

Ha&.fAinily-stKft-<iaie» 

Has-iiiufi-|Modua-relatioiiship& } ) 
Fig. 6. Car developni«nt ievcL 
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( EAgme. His-meoiber-inappnit* < Has-dcsign-variani, 

Has- fuet-economy . 
HAS'gearbox'intcrface* 
Has-variant-stan-daie, 
Has-commerciaJ^parameters } ) 

( EDKine, U-a-membcr-of, ( Product J ) 

(C<miittcrcial-p«aictcrs.HM'incnibcr-inappiiig, ( Has-namc, 

Has-vaiue ) ) 

( Engine. Has-rcUttsd-product, ( Igntcion } ) 
( Engine, Has-relaled-producv { Cevbox ) ) 
( Eaginc Has-oiember. { El 

E2.0t) ) 
Fig, 7. Engine definition level. 

Every identifiable information fact in an appli- 
cation environment corresponds to an object in a 
3DIS database. Simple, compound, and be- 
havioural entities in an application environment, 
attributes of objects and relationships among ob- 
jects, as well as object groupings and classifica- 
tions are all naodelled as objects. What distin- 
guishes different kind of objects in a 3DIS 
database is the set of structural and nonstructural 
(data) relationships defined on them. 

The concept which we have exploited to model 
multiple levels of abstraction is "instantiation/ 
classification". However the semantics of these 
terms art not defined in Ref. [ll Our intcrpreta- 
^ioiT is~th: a t an instance of a class is an object 
whose type is the class and which has values for 
the attributes of that class. For example. Engine 
(L8 litre, with turbo) is an instance of the object 
engine defined as EngM^ HAS (size (2.8 litre OR 
ZO litre) AND turbo (with OR without)). 



( El .8. ls-a-manber-«f, { Engine } ) 
(ELS. Has-fucl-coonomy, { 16 km/liue } ) 
( E1.&, Hfts-geaitojt-ialerfacc* { GKS } ) 
( El^, Has-vari*ni-stan-daic. ( 1993-3 \ ) 

<El,S.H»i-coaifi*cnaal-psi«njcicrs, I Eogine-»w*»L8»Tittbo=no ) ) 
Fig. Engine instance level (El. 8 only). 
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5.2, Using X-calculus for modelling multiple ab- 
straction levels 

The solution adopted in the structure editor is 
to model the form of final instances, Ic. the 
lowest abstraction level, in the racta-structure, 
and to model the mtennediate abstraction levels 
with A -calculus. This means for our purposes 
ihat: 

- the structure and content of a product variant 
are modelled in the meta-structure (level 2 in 

Fig. 4); 

- specific variants for customer orders are mod- 
elled as instances of the meta-structure (level 4 
in Fig, 4); 

- product families as cars, trucks and aeroplanes 
are modelled using A-calculus (level 3 in Fig. 
4X 

Fig, 10 shows the meta-structure for variants. 
This meta-structure is defined recursively be- 
cause components of a variant can be variants 
again. The LIST construct is used to model an 
arbitrary number of components, which are all 
variants again. 

Fig. U shows a small part of a car assembly 
variant (coded AVll) and its engine (coded 
El.St). This variant Is an instance of the meta- 
structure of Fig. 10, Now, we will use this specific 
instance to model the car family with its compo- 
nent families. We will replace specific instances 
by a parametrized A>function. The parameters of 
this function are used to define the precise pri- 
mary variants ot a iamiiy. An example will clanty 
this. 



valiant 

L 



sel] 



Bssambly 
variant 



COL 



names code= components 
car AV11 



rr 

etc etc 



i LISTj j 

variant etc 




SEL 



pnmafy 
vananl 



name= 
angine 



code= 
El.at 



Fig. 1 1. A specific car variant 



First we will look at a component family of the 
car» namely the engine. The engine has four 
variants, of vMch the selection is dependent on 
the commercial parameters "engine size" and 
"turbo". If we model the engine as a function, 
- the above mentic 



be used to invoke this function. 



eode vwrne code oomponanCi 



Fig. 10. M«ta-structure for variants. 



Engine( engine size = [1.8, 2.0], 
turbo « [yes, nol) 

with body: 

IF engine size =1.8 AND turbo = no 

THEN E1.8 
IF engine size « 2,0 AND turbo -= no 

THEN E2.0 
IF engine size 1.8 AND turbo = yes 

THEN E1.8t 
IF engine size « 2.0 AND turbo ^ yes 

THEN E2.0t 
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interface supports this interaction. 3D IS, on the 
other hand, is a database system which is best 
used in conjunction with sophisticated, and possi- 
bly data structure specific, user and application 
interfaces. In practice both systems have a role to 
play: the SE allows people to prototype and test 
their data structures whereas 3DIS provides a 
database environment in which the tested data 
structures can be implemented and used in a 
production environment. 



6. Conclusions 

This paper has tried to raise an awareness with 
respect to abstraction levels. The development of 
products, and product families in particular, 
shows that there are modelling problems which 
cannot be solved directly in relational or object- 
oriented databases. Forcing multiple abstraction 
levels in three database levels introduces more 
complex schema with inherent redundancy. Al- 
though this problem is generally known with ex- 
perienced database designers, not much attention 
has been paid to this subject in literature or 
software design. Two academic approaches, the 
3D1S and the Leeds Product Data Editor, have 
been developed to tackle multiple abstraction 
levels. They appear to be appropriate for mod- 
elling product families, but supported software of 
this kind is not yet available. 
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